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ABSTRACT 



A system for and a method of managing a communications 
network through the use of multiple network connections. 
The system prepares at least two transport service providers 
of a node for establishing a network connection with cor- 
responding transport service providers of another node and 
associates the at least two transport service providers with 
each other and with a requesting application. The system 
monitors network connection condition and determines 
availability and suitability of each network connection. The 
system selectively transmits information via a selected net- 
work connection. The system seamlessly establishes the 
multiple connections and transmits the information over the 
selected network connection and. is transparent, to the appli- 
cation. 

17 Claims, 13 Drawing Sheets 
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NETWORK COMMUNICATIONS SYSTEM 

MANAGER 

HELD OF THE INVENTION 

The present invention relates generally to communica- 
tions networks. More particularly, the present invention 
relates to a communications network system which provides 
a backup or redundancy capability through multiple network 
connections. 

BACKGROUND OF THE INVENTION 

Communication networks have become ubiquitous in 
today's society. For example, networks are used for such 
diverse purposes as internet searching and data transfer, 
satellite telecommunication networks, and process plant 
control. 

With communication systems supporting large scale pro- 
cessing plants and global telecommunication systems, the 
failure of the system can translate into thousands or even 
millions of dollars in lost product or time. In light of the cost 
of system failure and the widespread use of communications 
networks by industry, it is more important than ever to 
provide reliable systems which will ensure continuous deliv- 
ery of information in the most effective and efficient manner. 

In general a communications network system includes a 
plurality of inter-connected nodes. Each node will typically 
include a computer station. The computer station can range 
from a high end server or router to a work station to a 
desktop/laptop PC to a handheld personal digital system. 

At least one software application program (hereinafter 
referred to as "application") will be resident in each com- 
puter station. Such an application could be an internet web 
browser, a database program or a process plant systems 
manager program, for example. In order for the application 
to communicate over the network a stack of communication 
protocols arc necessary. An example of such a stack is the 
7-layer reference model approved by the International Stan- 
dards Organization. The protocols receive information from 
the application and prepare the information for tra n s mis sion. 
The protocols transmit the information via a network card to 
the network. The same occurs in reverse for incoming data. 

Each protocol stack includes a transport service provider 
(TSP) protocol, for example TCP/IP (Transmission Control 
Protocol/Internet Protocol). In order for the application and 
the TSP to communicate they must be compatible. In other 
words, they must talk the same language. However, since 
different entities typically design the applications and the 
TSPs, it is not uncommon for the two elements to be 
incompatible. 

To ensure compatibility between the applications and the 
TSPs, a node can 1) use only proprietary elements which are 
compatible by initial design, 2) use applications compatible 
with a variety of TSPs, or 3) provide an open standard. 

The first two options fail to provide a desirable solution to 
the compatibility issue. The use of proprietary systems limit 
one's options in features, capabilities and design when 
selecting a supplier for the applications and TSPs. This will 
also tend to lock a user into one system when expanding or 
upgrading the system. Designing the application to be com- 
patible with multiple TSPs or vice versa adds a significant 
amount of code to the items, thereby increasing complexity, 
time and effort in the design. This typically translates into 
higher costs for the item, decreased features or capabilities, 
and increased opportunity for failure. 

Another alternative is an interface which would reside 
between the application and the TSP. Such an interface 
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would provide an avenue for a variety of applications to 
communicate with a variety of TSPs which are not neces- 
sarily compatible. A node having an application and a TSP 
written to work with the interface can utilize any such 
application to communicate with any such TSP. 

An example of such an interface is Windows Socket 2.0 
(hereinafter referred to as "Winsock"). A group of software 
and hardware developers developed Winsock to resolve the 
aforementioned compatibility issue and to spur development 
of various and diverse applications and systems, g Winsock 
is an interface that is used by applications running on 
Windows 3.X, Windows for Workgroups, Windows NT, 
Windows 95, and future Windows operating systems, for 
example. 

Winsock is a .DLL (dynamic link library) and serves as 
the interface to the TSP. TCP/IP is the "language" that 
computers on the Internet use to communicate with each 
other. Winsock was initially written to take advantage of 
TCP/IP. FIG. 1 illustrates an example utilizing Winsock to 
communicate over a network. As shown in FIG. 1, Winsock 
acts as a layer between a Winsock compliant application and 
the TSP. The application tells Winsock what to do, Winsock 
translates these commands to the TSP, and the stack passes 
the data to the network. 

The use of Winsock allows a variety of applications, 
which have been written to comply with Winsock, to com- 
municate with a variety of TSPs which also have been 
written to comply with Winsock. 

The Winsock 2.0 DLL is defined by Microsoft Corpora- 
tion and is based on Berkeley Sockets. It allows both a 
connection and a connection-less communications path. The 
interface between the Winsock-DLL and the TSP is the 
Winsock 2.0 Service Provider Interface (SPI). The SPI 
allows any network card and protocol developer to create 
DLLs that can be easily plugged into the Winsock architec- 
ture. The interface between the TSP and the network card 
driver is typically proprietary and goes directly to the 
hardware driver. The Winsock architecture is designed to be 
backward compatible with the Winsock LI specification at 
a binary level. Therefore any Winsock 1.1 compliant appli- 
cation will not have to be recompiled when Winsock 2.0 is 
introduced into the system. For a better understanding of 
how to utilize Windows sockets and understand the Win- 
dows sockets programming language, reference may be 
made to Windows Sockets 2 Service Provider Interface 
Manual, Revision 2.2.2, Aug. 7, 1997 and the Windows 
Sockets 2 Application Programming Interface Manual, 
Revision 2.2.2, Aug. 7, 1997, which those skilled in the art 
will be familiar with. 

The introduction of Winsock provided a much needed tool 
for the use of heretofore- incompatible applications and 
TSPs. 

As stated above, the need for reliable communication 
networks is paramount in a number of industries. In net- 
worked systems which implement the Winsock architecture, 
several schemes have been set forth which attempt to 
provide satisfactory redundancy /backup systems for com- 
munication networks. A first system makes changes at the 
application level. The applications are written to provide for 
multiple network connections each time a single connection 
is required by the app heat ion. This requires complex 
changes to each application to implement a redundancy/ 
backup scheme. This solution is costly and requires each and 
every individual application developer to either revise an 
existing application or take more lime to create a new 
application. Applications which arc not specifically written 
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to implement redundancy/backup would not provide a reli- FIG. 2 is a block diagram of a conventional communica- 

able system. A second solution implements another layer of tions network. 

code which resides between the Winsock DLL and any and pjQ 3 ^ a block diagram of a node of a communications 

all resident applications. This requires an additional program network implementing the present invention, 

which would have to work with application programming 5 nG 4 ^ a block diagram of a network communications 

interfaces for each and every application with which it memorv 0 f fig 3 

wishes to work. A third solution of providing backup/ ™ , c 

redundancy can be implemented at the hardware level. This FIG. 5 is a flow chart illustrating an implementation of an 

solution provides multiple communication paths through element of the present invention. 

multiple physical connections in a single hardware network p\Q 6 is a flow chart illustrating an implementation of 

card. This has been done by hardware network card manu- another element of the present invention, 

facturers who make Ethernet boards that have two ports on FIG 7 is a flow chart illustrating an implementation of 

them. The redundancy/backup scheme is defined in hard- cm Qf ^ m inventiorK 

ware and drivers so that the operating system sees a „ . a . 1 -„ .• , , f 

sundard single media network card. This scheme includes a FIG. 8 is a flow chart illustrating an implementation of 

very high cost due to the limited availability of these types 15 another element of the present invention. 

of cards, limited choice for hardware manufacturers, and FIG. 9 is a flow chart illustrating an implementation of 

inflexibility of the redundancy/backup scheme since they are another element of the present invention. 

implemented in hardware and low level drivers. The mul- ^ Q 10 ^ a flow CDarl illustrating an implementation of 

tiple physical communication media is limited to a total of ^ elcment of the present invention. 

two and are required to be the same exact physical network 20 ^ ^ ^ & ^ ^ &n teplemcntation of 

flight of the foregoing drawbacks presented by conven- another element of tbe present invention, 
tional systems, there are currendy no systems available FIG. 12 is a flow chart illustrating an implementation of 
which fully utilize the advantages of the Winsock architec- another element of the present invention. 
Cure to provide a communications network system which 25 fig. 13 is a flow chart illustrating an implementation of 
will effectively and efficienUy provide reliable redundant/ ano thcr element of the present invention, 
backup network connections. RG 14 & a block diagram illustrating two network 
SUMMARY OF THE INVENTION computer stations. 
The present invention provides a system for and a method ^ piG. 15 is a flow chart illustrating an example of a 
of managing a communications network system to ensure redundancy/backup scheme used in conjunction with the 
information can be continuously and reliably transmitted present invention, 
through the use of multiple network connections. The net- 
work comprises a plurality of nodes or computer stations. DETAILED DESCRIPTION OF THE 
Each node is capable of r unnin g one or several applications. INVENTION 
Each node comprises a plurality of TSPs linked to a network 35 . 
d^tcr ^rTSP-network driver combination is capable of . The present mvenuon vnll now be As^mnnjim- . 
establishing a network connection between itself and a toon with the attached figure^ wherem hke ^elementi ; a e 
corresponding combination residing at another node. Each ***** with Uke numerals. FIG. 2 illustrates an_ example 
node also includes an interface linking one of a plurality of of a bas.c commumcations network sys en. wh.cn utiLzcs 

Vacations resident and active in theLdc to anyone of the 40 ^^rT^'^^^^J&^lte 
TSPS. The interface enables diverse software application N nodes 4. Each node 4 b connected to each of M networks 
programs to communicate with various transport service « The commumcations network system 2 may be, for 
providers. example, the Internet, an intranet, or a process plant net- 
When a particular application requires a single network work, 
connection and request such a Connection through the 45 RG. 3 illustrates one of the nodes 4. The node may also 
interface, the present invention responds to the application be referred to as a computer wherem the computer includes 
reqlcst for the network connection and prepares at least two a CPU 8, an tnput dev.ee 10. an output dev.ee 12, software 
ofthc transport service providers for establishing a network application program memory 14, network commxmications 
connection through each of the at least two transport service program memory 16 and a plurality of network cards 18. The 
providers and associates the at least two transport service 50 CPU 8 may be for example, an Intel Pentium II processor 
providers with each other and the requesting application. operating in a Windows 95 envronment. The mput dev.ee 
The network connection is established between each of the 10 may be any of a variety of mput devces such as a mouse 
at least two transport service providers of a first node and a keyboard, a vo.ee recogn.t.on system, or other input 
corresponding transport service^ providers of a second node. device. The output device 12 may be any of a variety of 
The pre^ntinvention monitors the at least two network 55 devKxssu<AasadispIaymon.tororaprmter.Themernones 
connections and determines the availability of each connec- 14 and 16 may be any computer memory «P*bfeof storing 
tion. The present invention then selectively transmits appli- program code ^eluding for example, a hard disk dnve, read 
cation program information via a selected one of the net- only memory (ROM), random access memory (RAM), or an 
work connections. °P tical dlsk ^ve. Tbe memor.es 14 and 16 may be .mple- 
The present invention seamlessly establishes the multiple <*> mented as a s.ngle memory una or as muluple memory 
conned and selectively transmits the information over The network cards 18 may be. fo. ™™£* *° a ^croc 
, , , , 7 - . . trt lrM1 card, a card for a wireless local area network (LAN), or a 
the selected network connection and us transparent to the ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ may 

application. aU ^ or any combination thereof. Application 

DESCRIPTION OF THE DRAWINGS 65 mcn iory 14 may store any one of a variety of applications 

FIG. 1 Is a flow chart illustrating implementation of a including, for example, an Internet web browser, a factory 

Winsock interface in a network protocol stack. process control program, or an intranet database program. 
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The network communications memory 16 includes all of the 
programs necessary for connecting to a network and trans- 
mitting information to and receiving information from 
another node". 

FIG. 4 illustrates the network communications memory 
16 in more detail. The memory 16 includes an interface 
module 20, for example the Winsock-DLU and a network 
manager 22 which connects to at least two of the multiple 
protocol stacks 24. Each protocol stack 24 is connected to a 
network card 18. Each protocol stack comprises a transport 
service provider (TSP) 26 and a network card driver 28. The 
combination of the protocol stack 24 and network card 18 
comprises a network connection channel from each indi- 
vidual node 4 to a particular network 6. 

The network manager 22 of the node 4 operates with the 
other elements of the node as follows. The network manager 
22 operates in a first manner when managing a node in a 
server mode, as illustrated in FIG. 5, and in a second manner 
when managing a node in a client mode, as illustrated in 
FIG. 6. In either a server node or a client node, one of the 
applications 30 residing in application memory 14 is acti- 
vated. The application 30 requires a network connection to 
transmit or receive information. The application 30 requests 
a single network connection from the interface 20. The 
interface 20 passes this request to the network manager 22. 
In response to the request the network manager 22 prepares 
at least two of the protocol stacks 24 to establish a network 
connection. The network manager 22 selects as many pro- 
tocol stacks as is required by the redundancy/backup scheme 
it is working under, as discussed below. The protocol stacks 
24 are prepared for connection to another node and are also 
associated with each other and the requesting software 
program application. For example, if the requesting appli- 
cation is a web server the protocol stacks are defined by the 
socket number 80 which also designates the web server 
application. 

The following flow charts are meant only to assist in 
understanding the present invention and are not intended to 
limit the scope of this specific embodiment. 

An example of the procedure the network manager 22 
follows in a server mode is illustrated in the flow chart of 
FIG. 5. The network manager 22 is activated when the 
interface 20 makes a call requesting a single network 
connection. Operation of the network manager 22 begins 
with a call to a start step 32. The network manager 22 then 
calls a server stack connector 34. The procedure followed by 
the server stack connector 34 is illustrated in the flow chart 
of FIG. 7. The server stack connector procedure begins at 
start step 340. In step 342, the server stack connector 34 
initializes X service provider resources in accordance with a 
preselected redundancy /backup scheme, as discussed below. 
In step 344, the server stack connector 34 creates an end 
point for communication of the X service providers. In step 
346, the server stack connector 34 assigns an address to each 
of the X service providers. In step 348, the server stack 
connector 34 listens for incoming connection requests on all 
of the X service providers. In step 350, the server stack 
returns control to the network manager 22. 

The network manager 22 then calls a server connection 
manager 36. The procedure followed by the server connec- 
tion manager 36 is illustrated in the flow chart of FIG. 8. 
Operation of the server connection manager 36 begins at a 
start step 360. In step 362, the server connection manager 36 
determines if an initial connection has been requested from 
another node. If a connection has not been requested, the 
server connection manager 36 loops back to step 362. If an 
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initial connection has been requested, in step 364 the server 
connection manager 36 determines if it is an appropriate 
request. An appropriate request includes one which has the 
correct address and the correct socket number and includes 
5 information indicating it has come from the network man- 
ager of another node. This information may be for example 
some type of tag in the form of bits appended to the request 
call. An inappropriate request includes one which was 
initiated by a client node that did not use the network 
10 manager 22. Such a request would not include the appended 
tag. If an inappropriate request is made, the request is 
discarded in step 366 and the server connection manager 36 
loops back to step 362. If an appropriate request has been 
made, the server connection manager 36 sets a countdown 
15 timer to a preselected period Tl at step 368. Once the 
countdown timer has been set the server connection manager 
36 makes a call to a network connector in step 369. The 
network connector establishes a connection between the 
requested protocol stack and the corresponding protocol 
20 stack of the requesting node. Once the connection is made 
the server connection manager 36 makes a call to a status 
manager in step 370. The status manager monitors and 
marks which TSPs have and have not been connected. If a 
connection has been established the connection condition is 
marked as available. Once the status of the TSP and corre- 
sponding network connection is marked the server connec- 
tion manager 36 checks if period Tl has elapsed, in step 371. 
If Tl has not elapsed, in step 372, the server connection 
manager 36 checks for another connection request If a 
30 connection request has not been made the server connection 
manager 36 loops back to check the period Tl. The server 
connection manager 36 continues in this loop until another 
connection request has been made or period Tl elapses. If 
another connection request has been made the server con- 
35 nection manager 36 continues to step 373. If the connection 
request received in step 372 is inappropriate, it is discarded 
in step 374 and the service connection manager 36 loops 
back to step 371. If the connection request is appropriate, a 
connection is made by the network connector, the status 
40 manager marks the TSP and corresponding network con- 
nection as connected and available and the period Tl is 
checked again. Once the period Tl has elapsed, the server 
connection manager 36 returns control to the network man- 
ager 22. 

45 In a client mode the network manager 22 operates slightly 
differently from the server mode. In the client mode the 
network server 22 calls a client stack connector 52. The 
procedure followed by the client stack connector 52 is 
illustrated in the flow chart of FIG. 9. Operation of the client 

50 stack connector procedure begins at step 520. In step 522, 
the client stack connector 52 initializes X service provider 
resources in accordance with the preselected redundancy/ 
backup scheme. In step 524, the client stack connector 52 
creates end points for communication of the X service 

55 providers. In step 526, the client stack connector 52 assigns 
an address to each of the X service providers. In step 528, 
the client stack connector 52 returns control to the network 
manager 22. 

The network manager 22 then calls a client connection 
60 manager 54. The procedure followed by the client connec- 
tion manager 54 is illustrated in the flow chart of FIG. 10. 
Operation of the client connection manager 54 begins at step 
540. In step 542, the client connection manager 54 sends a 
connection request to a server node for all X service pro- 
65 viders. In step 544, the client connection manager 54 sets a 
countdown timer to a preselected period T2. In step 546, the 
client connection manager 54 checks and determines if an 
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initial connection has been established with the server node. 
If an initial connection has not been established, in step 548, 
client connection manager 54 checks if the period T2 has 
elapsed. If the period has not elapsed the client connection 
manager 54 loops back to step 546. If the period has elapsed, 
in step 558, the client connection manager 54 returns control 
to the network manager 22. 

If the connection has been established, the client node will 
receive a signal from the server node. Once an initial 
connection has been established, the client connection man- 
ager 54 calls the status manager in step 550. As in the server 
mode, the status manager marks the particular TSP and 
corresponding network connection as connected and avail- 
able. In step 552, the client connection manager 54 checks 
if period T2 has elapsed. If the period T2 has not elapsed, in 
step 554, the client connection manager 54 checks to deter- 
mine if all of the X connections have been established. 

If all of the connections have not been established, in step 
556, the client connection manager 54 checks if another 
connection has been established. If another connection has 
not been established the client connection manager 54 loops 
back to step 552. IF another connection has been established 
the client connection manager 54 loops back to step 550. If 
all of the connections have been established, in step 558, the 
client connection manager 54 returns control to the network 
manager 22. If the period T2 has elapsed before all of the 
connections have been established, in step 558, the client 
connection manager 54 returns control to the network man- 
ager 22. 

In both the server mode and the client mode the network 
manager 22 then calls a report manager 38. The report 
manager 38 reports the status (also referred to as 
"condition") of the individual TSPs 24 and corresponding 
network connections to a report log using the information 
established by the status manager. The report log indicates 
which TSPs have successfully connected to the network and 
which have not, within the preselected time period. Once the 
report manager 38 has reported the status of the various 
TSPs, the network manager 22 calls a receive manager 40. 

The procedure followed by the receive manager 40 is 
illustrated in the flow chart of FIG. 11. Operation of the 
receive manager 40 begins at step 402. In step 404, the 
receive manager 40 sets a counter x equal to one. In step 406, 
the receive manager 40 determines if an incoming message 
is present at a TSP,. If a message is not present, in step 408, 
the receive manager 40 determines if the counter x is equal 
to X, which is equal to the number of TSPs selected by the 
redundancy /backup scheme currently in operation. If 
counter x is not equal to X, in step 410, the receive manager 
40 increments the counter x by 1 and then loops back to step 
406 to determine if the next TSP has a message. If a message 
is present on the TSP, in step 412, the receiver manager 40 
calls a transmission manager. The transmission manager 
retrieves the message present on the TSP and delivers it to 
the appropriate application. Once the message is retrieved 
and delivered, the counter x is again checked to see if all of 
the current TSPs have been checked. Once all the TSPs have 
been checked, at step 414, the receive manager 40 returns 
control to the network manager 22. 

The network manager 22 then calls a health manager 42. 
The procedure followed by the health manager 42 is illus- 
trated in the flow chart of FIG. 12. Operation of the health 
manager 42 begins at step 420. In step 422, the health 
manager sets a counter x equal to one. In step 424, the status 
of a connection through a TSP X is determined. In determin- 
ing if the network connection is alive, the health manager 42 
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calls the status manager. The status manager continuously 
checks the status of every network connection which the 
particular redundancy /backup scheme requires. This is 
achieved by a heart beat checker, for example. The heart beat 
checker sends a pulse down each network connection. If a 
return signal is received from the other end of the network 
connection, the status manager knows the network connec- 
tion is alive and available and reports it as such to a status 
report. If a return beat is not received the network connec- 
tion is marked as dead and unavailable in the status report. 
The status manager will repeatedly check the network 
connection after a preselected time period. If the node 
receives a heart beat request from another node, the status 
manager will mark the network connection as alive and 
checked and not check it the next period. 

Once it is determined that the network connection is alive, 
Ln step 426, the health manager 42 checks the "health" of the 
network connection. This is determined by variables asso- 
ciated with information transmission which are monitored 
every time information is transmitted over a particular 
network connection. These variables include but are not 
limited to transmit time, transmit cost, and wait period 
before transmission begins. In step 428, the health manager 
then reports the network connection health to a health report. 
Id step 430, the health manager 42 determines if all of the 
required network connections have been checked. This is 
accomplished by checking if the counter x equals X. If all of 
the network connections have not been checked in step 432, 
the counter is incremented by one, and the health manager 
42 loops back to step 424 to check the next network 
connection. If a network connection is found to be "dead" 
the death is reported to the status report, in step 434. Once 
all of the network connections have been checked, in step 
436, the health manager 42 returns control to the network 
manager 22. 

The network manger 22 then calls the transmission man- 
ager 44. The procedure followed by the transmission man- 
ager 44 is illustrated in the flow chart of FIG. 13. Operation 
of the transmission manager 44 begins at step 440. In step 
442, the transmission manager 44 determines if any of the 
applications 30 are ready to transmit information. If an 
application has called the interface 20 to transmit the inter- 
face 20 will call the network manager 22 to transmit. If a 
program wishes to transmit information, in step 444 a health 
report established by the health manager 42 is reviewed. 
Using the predetermined redundancy/backup scheme, the 
status report and the health report, in step 446, the trans- 
mission manager 44 determines which is the most suitable 
connection to use. In step 448, the transmission manager 44 
selects the most suitable connection. Once the connection is 
selected, in step 450, the transmission manager 44 directs 
the information to the proper protocol stack for transmis- 
sion. Once the information is directed, at step 452, the 
transmission manager 44 returns control to the network 
manager 22. If none of the applications wish to transmit 
information, the transmission manager 44 simply returns 
control to the network manager 22. 

In step 46, the network manager 22 determines if a request 
to disconnect the connection has been received. If no dis- 
connect request is present the network manager 22 loops 
back to step 40 and calls the receive manager. If a disconnect 
request has been received the network manager 22 discon- 
nects the connections associated with the disconnect request. 
The network manager 22 then shuts down and waits for 
another request from a application to establish a network 
connection. 

An example of a network system which does use the 
present invention and one that docs not use the present 
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invention will be helpful in better understanding the present 
invention. FIG. 14 illustrates two personal computers 600 
and 602, each having two independent network cards 604, 
606, 608 and 610. A first network, for example an Ethernet 
network, 612 connects card 604 to card 608. A second 
independent network, for example but not necessarily 
another Ethernet network, 614 connects card 606 to card 
610. Since each computer 600, 602 has two network cards, 
each computer has two network addresses. In this example 
the first computer 600 has addresses PC1IP1 and PC1IP2 
and the second computer 602 has addresses PC2IP1 and 
PC2IP2. In this example both computers are running Win- 
sock software. The first computer 600 is running in the client 
mode and the second computer 602 is running in the server 
mode. 

The particular application running on the computers is 
unimportant to the operation of the Winsock program and 
the network manager for purposes of this example. 
However, various application programs may introduce 
changes in the low level operation of the interface and the 
manager without affecting the overall purpose and scope of 
the present invention. Table 1 presents an example of 
Winsock calls when the present invention is not operating. 
The operation of the Winsock calls results in a single 
network path over one of the networks 612 or 614. In this 
example the first network 612 is selected. Either network can 
be selected, and there is usually no reason to prefer one over 
the other. Winsock passes the function calls to a network 
protocol stack corresponding the first network 612 (as 
discussed above) and then assumes that the same stack is to 
be used for all future communications. Therefore all packets 
of information the application wishes to transmit over the 
network will be routed to the first network 612 regardless of 
the health or status of the first network 612. The network 
sucks of the two networks 612, 614 are unaffected by and 
do not cooperate with each other. 

When the present invention, referred to as the network 
manager, is installed on each of the computers 600, 602 and 
configured as the default service provider, the Winsock 
program passes the function calls to it instead of one of the 
service providers of the various protocol stacks. Tables 2 and 
3 show an example of the steps followed by the server and 
client for a particular application program when the network 
manager is operational The first three steps of both the client 
and the server are the same as in the example wherein the 
network manager is not running except that both networks 
are prepared for transmitting information from and receiving 
information for the application and both networks are asso- 
ciated with each other and the application. In other words, 
every time Winsock receives a call from an application to 
establish a network connection Winsock passes that call to 
the network manager. For every call the network manager 
receives from Winsock to establish a single network 
connection, the network manager will establish multiple 
network connections. In this example two connections are 
established. However, the number of connections will only 
be limited to the number of available network cards. Further, 
the application is unaware that multiple network connections 
will be established. The first four steps of table 2 correspond 
generally to the operation of the server stack connector 34, 
discussed above and the first three steps of table 3 corre- 
spond generally to the operation of the client stack connector 
52, discussed above. 

After the two network connections are prepared and 
associated with each other and the application, the server 
waits until it receives a connection request from a client. In 
step 4 of table 3, the client requests a connection to the 
server for all of the service providers. Step 4 of table 3 
corresponds generally to the client connection manager 54. 
In step 5 of table 2, the server receives a first connection 
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request from a particular client. Step 5 of table 2 corresponds 
generally to the server connection manager 36. 

After all of the available connections have either been 
established or determined dead as reported by the report 
manager 38, the network manager in both the server and the 
client begins sending and receiving information on the 
connected networks. Steps 6-13 of table 2 and steps 5-12 of 
table 3 correspond generally to the receive manager, health 
manager and transmission manager discussed above. 

In the example set forth in tables 2 and 3, the first data 
information send occurs at step 5 of table 3. In this example, 
the network manager has directed the information to service 
provider #1 and therefore the information is sent through 
service provider #1. The network manager selects the ser- 
vice provider to send the information based upon the infor- 
mation gathered by the health manager, as discussed above 
and the particular redundancy /backup scheme it is running 
under, as discussed below. Further, the reception of data on 
a particular service provider is determined by the decision 
made by the sending node. The sending node selectively 
chooses a service provider for transmission in the same 
manner discussed above. The particular service providers 
selected in this example merely illustrates one potential 
combination among a virtually infinite set of combinations. 

Another example would have the server network manager 
determining that service provider #1 is unavailable (dead) 
and therefore will select service provider #2 every time the 
server needs to transmit information. At the same time, the 
server network manager will continuously recheck the status 
of service provider #1 so that it will know when it has the 
option to again transmit information on service provider #1. 

The phrase "redundancy scheme," as used above is 
intended to mean a template which the network manager 22 
uses to select a particular network connection to transmit 
information from an application in one node to an applica- 
tion in another node. The redundancy scheme will assume 
all of the available network connections are alive and 
provide a method for selecting a connection dependent upon 
the task the communications system is undertaking. 

An example of one redundancy scheme is illustrated in 
the flow chart of FIG. 15. Using the network described 
above in FIG. 14, the redundancy scheme of FIG. 15 simply 
alternates the selection of the two connections. The first data 
transmission would be sent through the first network 612, 
the second data transmission would be sent through the 
second network 614, the third data transmission would be 
sent through the first network 612 and so on. 

This redundancy scheme will be taken into account by the 
network manager 22 when selecting a network connection. 
However, if one of the network connections is found to be 
"dead" then the network manager 22 will only transmit data 
through the other connection. The network manager 22 will 
periodically check the "dead" connection, as discussed 
above, to determine if the connection is "alive." Once the 
connection is "alive" again, the network manager 22 will 
return to following the redundancy scheme. 

The redundancy/backup scheme illustrated in FIG. 15 is 
merely an example of one possible scheme the network 
manager 22 can be set to follow and is not intended to limit 
the scope of the present invention. 

The present invention may be embodied in other specific 
forms without departing from the spirit or essential attributes 
thereof and, accordingly, reference should be made to the 
appended claims, rather than to the foregoing specification, 
as indicating the scope of the invention. 
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TABLE 1 



Normal Winsock 2.0 Client/Server Program Execution 



Client 



Winsock 
Step Functions 



Winsock 
Actions 



Service 

Provider 

Functions 



5 WSAStartup Initialize 

Winsock 
resources 
and call 
WSPStartup 

6 socket call 

WSPSocket 



WSPStartup 



7 bind 



8 connect 



call 

WSPBind 
call 

WSPConncct 



WSPSocket 



WSPBind 



WSPConncct 



10 send 

11 

12 

13 rccv 

14 shutdown 



IS closcsocket 



call 

WSPScnd 



call 

WSPRecv 
call 

WSPShutdown 



call 

WSPOoseSocket 



WSPScnd 



WSPRecv 



WSPShutdown 



Server 



Service 

Provider 

Functions 



Winsock 
Functions 



Winsock 
Actions 



Service 

Provider 

Functions 



WSPOose-Socket 



WSAStartup Initialize 
Winsock 



WSPStartup 



socket 



bind 



listen 



resources 
and call 
WSPStartup 
call WSPSocket 



Call WSPBtnd 



WSPSocket 



WSPBind 



call WSPListcn WSPListco 



Initialize 
service 
provider 
resources 

Create an 
end point for 
communication 
Assign a 
local name to an 
unnamed socket 
fniKate a 
connection 
on a specified 
socket 



accept 



call WSPAccept WSPAccept 



Send data 



Receive data 
from socket 
shutdown a 
part of a full- 
duplex 
connection 
Remove 
socket from 
socket 

reference list 



recv 
send 

shutdown 



dosesocket 



call WSPRecv 



call WSPSend 



call 

WSPShutdowQ 



call 

WSPOoseSocket 



WSPRecv 



WSPSend 



WPSHutdown 



Service 

Provider 

Actions 



Initialize 
service 
provider 
resources 

Create an 
end point for 
communication 
Assign a 
local name 
to an unnamed 
socket 
Listing for 
incoming 
connections 



WSPOose-Socket 



An incoming 
connection 
is accepted 
and associated 
with a new 
socket 



Receive data 
from socket 
Send data 



shutdown 
part of a full- 
duplex 
connection 
Remove 
socket from 
socket 

reference list 



TABLE 2 



Winsock 
Step Function 



Winsock 
Actions 



Winsock 2.0 Server Program Execution using MWTSPM 

Server 



MWTSPM 
Functions 



MWTSPM 

Actions - 



Service 
Provider #1 
Functions 



Service 
Provider #1 
Actions 



Service 
Provider 
ffl Functions 



Service 
Provider 
#2 Actions 



WSA- 
Startup 



2 socket 



Initialize 

Winsock 

resources 

and call 

WSPStartup 

call 



WSPStartup 



WSPSocket 



Initialize 
service 
providers 
resources 

call 



WSPStartup 



WSPSocket 



Initialize 
service 
provider 
resources 

Create an 



WSPStartup 



WSPSocket 



Initialize 
service 
provider 
resources 

Create an 



US 6,192,414 Bl 



13 



14 



TABLE 2-continued 



Winsock 2.0 Server Program Execution using MWTSPM 

Server 



Winsock 
Step Function 



Winsock 
Actions 



MWTSPM 

Functions 



MWTSPM 
Actions 



Service 
Provider #1 
FundioDS 



Service 
Provider #1 
Actions 



Service 
Provider 
#2 Functions 



Service 
Provider 
tf2 Actions 



3 bind 



WSPSocket 
call 

WSPBind 



4 lisle n 



5 accept 



call 

WSPListen 



call 

WSPAccept 



WSPSocket 

of SP1 and SP2 

WSPBind Assign address 

to first network 
and rind the' 
address on the 
other networks 
which correspond 
to address on 1st 
network and call 
WSPBind of SP1 
and SP2 with the 
appropriate 
addresses 

WSPUstcn call 

WSPListen 
for SP1 and SP2. 
Wail for incoming connection 



WSPBind 



end point for 
communication 
Assign a 
local address 
to an unnamed 
socket 



WSPBind 



end point for 
communication 
Assign a 
local address 
to an unnamed 
socket 



WSPListen Listen for 
incoming 
connections 
from Client (See Step 4 of Table 3) 



WSPListen 



WSPAccept 



Setup the connect WSPAccept 


An incoming 


manager to 


connection is 


determine when ail 


accepted and 


pipes receive a 


associated 


connection 


with a new 


request from the 


socket 


same client and 




after one of the 




pipes has received 




a connection 




request call 




WSPAccept of the 




requested pipe. 




Wait some period of 




time for the other 




pipe's connection. If 




none received then 




operate in noo- 




rcdundaot mode. 





WSPAccept 



Listen for 

incoming 

connections 



An incoming 
connection is 
accepted and 
associated 
with a new 
socket 



Wait for incoming data request #1 from Client (See step 5 of Table 3) 



6 


recv 


call WSPRecv 


WSPRecv 


call 


WSPRecv Receive data 










WSPRecv of 


from socket 










the appropriate 












service provider 




7 


send 


call 


WSPSend 


call 


WSPSend Send data 






WSPSeod 




WSPSend of one 












of the service 












providers 










Wait for 


incoming data request Wl from Client (See step 2 of Table 3) 


8 


recv 


call 


WSPRecv 


call 








WSPRecv 




WSPRecv 












of the appropriate 












service provider 




9 


send 


call 


WSPSend 


Call 








WSPSend 




WSPSend 





WSPRecv 



WSPSend 



Receive data 
from socket 



Send data 



of one of the 
service providers 

Wait for incoming data request #3 from Client (See step 9 of Table 3) 



10 recv 



11 send 



12 recv 



call 

WSPRecv 
call 

WSPSend 



call 

WSPRecv 



WSPRecv 



WSPRecv 



Receive data 
from socket 



call WSPRecv 
of the appropriate 
service provider 
call WSPSend 
.of one of the 
service providers 

Wait for Incoming data request #4 from Client (See step 12 of Table 3) 



WSPSend 



WSPSend 



Send data 



WSPRecv 



call WSPRecv 
of the appropriate 
service provider 



WSPRecv 



Receive data 
from socket 
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TABLE 2-continued 



Winsock 2.0 Server Program Execution using MWTSPM 

Server 



Winsock Winsock 
Step Function Actions 



MWTSPM 
Functions 



MWTSPM 

Actions 



Service 
Provider #1 
Functions 



Service 
Provider #1 
Actions 



Service 

Provider 

#2 Functions 



13 send 



WSPSend 



14 shutdown call 

WSPShutdown 



WSPSend call WSPSend 

of one of the 
service providers 

WSPShutdown call 

WSPShutdown 

of SP1 and SP2 



15 close- 
socket 



call 
WSP- 

QoseSocket 



WSP- 

CloseSocket 



call 

WSPCloseSockct 
of SP1 and SP2 



WSPShutdown shutdown 

part of a full- 
duplex 
connection 
Remove 
socket 
from socket 
reference list 



WSPSend 



WSPShutdown 



Service 
Provider 
#2 Actions 



WSPClose- 
Sockct 



WSPClose- 
Sockct 



send data 



shadows 
part of a full- 
duplex 
connection 
Remove 
socket 
from socket 
reference list 



TABLE 3 



Wmsock 2-0 Client Program Execution using MWTSPM 



Client 



Winsock Winsock 
Step Functions Actions 



1 WSA- 
Startup 



2 socket 



3 bind 



fniH»h'7y. 

Winsock 
resources 
and call 
WSPStartup 
call 

WSP Socket 
call WSPBind 



MWTSPM 
Functions 

WSPStartup 



MWTSPM 
Actions 

Initialize 
service 
providers 
resources 



Service 
Provider #1 
Functions 

WSPStartup 



WSPSockct 



WPSSocket 



WSPBind 



4 connect call 

WSPConnect 



5 send 



call WSPSend 



call 

WSPSockct 
of SP1 and SP2 
Find the address 
on the other 
network and call 
WSPBind 
of SP1 and SP2 
with the 
appropriate 
addresses 
call 

WSPConnect 
of SP1 
and SP2 
call WSPSend 
of one of the 
service providers 
Wait for response from request »1 from Server (See step 



Service 
Provider #1 
Actions 

Initially^ 

service 

provider 

resources 

Create an 
end point for 
communication 



Service 
Provider #2 
Functions 



Service 
Provider #2 
Actions 



WSPStartup initialize 
service 
provider 
resources 



WSPSockct 



WSPConnect 



WSPSend 



WSPConnect 



WSPSend 



Initiate a 
connection 
on a specified 
socket 
Send data 



7 of Table 2) 



6 recv 



7 send 



call 

WSPRecv 



call 

WSPSend 



WSPRecv 



WSPRecv 



Receive data 
from socket 



call 

WSPRecv 
of the appropriate 
provider 
call 

WSPSend 
of one of the 
service providers 

Wait for response from request #2 from Server (Sec step 9 of Tabic 2) 



WSPSend 



8 recv 



9 send 



call WSPRecv 



call WSPSend 



WSPRecv 



WSPSend 



WSPSend 



Send data 



call WSPRecv 
of the appropriate 
service provider 
call WSPSend 
of the service 
providers 

Wait for response from request #3 from Server (See step 11 of Table 2) 



10 recv 



call WSPRecv 



WSPRecv 



call WSPRecv WSPRecv 
of the appropriate 
service provider 



Receive data 
from socket 



Create an 
end point for 
communication 



WSPConnect 



Initiate a 
connection 
on a specified 
socket 



WSPSend 



Send data 



WSPRecv 



Receive data 
from socket 
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TABLE 3-continued 



Winsock 2.0 Client Program Execution using MWTSPM 



Client 



WLosock Winsock 
Step Functions Actions 



MWTSPM 

Functions 



MWTSPM 
Actions 



Service 
Provider #1 
Functions 



Service 
Provider #1 
Actions 



Service 
Provider #2 
Functions 



Service 
Provider #2 
Actions 



11 send 



call WSPSend 



WSPSend 



call WSPSend 
of the service 
provider 

Watt for response from request #4 from Server (See step 



WSPSend 



WSPSend 



13 of Table 2) 



12 recv 



call WSPRccv 



13 shutdown call 

WSPShutdown 



14 close callWSP- 
socket OoseSockct 



WSPRccv call WSPRccv 

of the appropriate 
service provider 

WSPShutdown call 

WSPShutdown 
of SP1 and SP2 



WSPClose- 
Socket 



call 

WSPSaoseSocket 
of SP1 and SP2 



WSPShutdown 



WSPClosc- 
Sockct 



shutdown 
part of a full- 
duplex 
connection 
Remove 
socket 
from socket 
reference list 



WSPRccv 



WSPSShut- 
down 



WSPClosc- 
Sockct 



Receive data 
from socket 

shutdown 
part of a full- 
duplex 
connection 
Remove 
socket 
from socket 
reference list 
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What is claimed is: 

1. A method of managing a communications network 
having a plurality of nodes, each node capable of running at 
least one of a plurality of applications, and a plurality of 
transport service providers, each transport service provider 
linked to a network driver for establishing a network con- 30 
nection and an interface linked to the at least one application 
for enabling any of the plurality of applications to commu- 
nicate with each of the plurality of transport service 
providers, the method comprising the steps of: 

in each of a first and a second node, preparing at least two 35 
of the plurality of transport service providers for estab- 
lishing a network connection through each of the at 
least two transport service providers and associating 
them with each other and an application in response to 
a request from the application to the interface for a ^ 
single network connection; 

establishing network connection between each of the at 
least two transport service providers in the first node 
and corresponding transport service providers in the 
second node; 

monitoring and deterrnining network connection condi- 
tion; and 

selectively transmitting information via a selected one 
network connection. 

2. A method as set forth in claim 1, further comprising the 5Q 

steps of: 

in the first node, monitoring request for connection 
received from the second node to connect one of the at 
least two transport service providers in the first node to 
a corresponding transport service provider in the sec- 55 
ond node; 

executing the establishing step in response to a connection 
request; 

after a first request for connection from the first node has 
been received, monitoring for a preselected period of 60 
time connection status of all of the at least two transport 
service providers to determine if each of the transport 
service providers has received a request for connection 
from the first node; 

after the preselected period of time has elapsed, reporting 65 
the connection status of the at least two transport 
service providers to the log. 



3. A method as set forth in claim 2, further comprising the 
steps of: 

in the second node, monitoring requests for connection 
received from the first node to connect one of the at 
least two transport service providers in the second node 
to a corresponding transport service provider in the first 
node. 

4. A method as set forth in claim 1, further comprising the 
steps of: 

monitoring the at least two transport service providers for 

incoming information; and 
fetching and transferring incoming information to the 

appropriate application. 

5. A method as set forth in claim 1, wherein network 
connection condition comprises network connection 
availability, cost, speed and wait time. 

6. A method as set forth in claim 1, wherein network 
connection selection is based upon one of a plurality of 
available redundancy schemes and network connection con- 
ditions. 

7. A method of managing a client-server communications 
network having a plurality of nodes, each node capable of 
running at least one of a plurality of applications and a 
plurality of transport service providers, each transport ser- 
vice provider linked to a network driver for establishing a 
network connection and an interface enabling any of the 
plurality of applications to communicate with each of the 
plurality of transport service providers, the method com- 
prising the steps of: 

in each of a first and a second node, preparing at least two 
of the plurality of transport service providers for estab- 
lishing a network connection through each of the at 
least two transport service providers and associating 
them with each other and an application in response to 
a request from the application to the interface for a 
single network connection; 

monitoring requests for connection received by the first 
node from the second node to connect one of the at least 
two transport service providers in the first node to a 
corresponding transport service provider in the second 
node; 

establishing network connection in response to a connec- 
tion request from the second node between the 
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requested transport service provider of tbe first node 
and the corresponding transport service provider of the 
second node each time the first node receives a request 
for connection; 

after a first request for connection from the second node 
has been received, monitoring for a preselected period 
of time connection status of all of the at least two 
transport service providers to determine if each of the 
transport service providers has received a request for 
connection from the second node; 

after the preselected period of time has elapsed, reporting 
the connection status of the at least two transport 
service providers to a log; 

monitoring and determining network connection condi- 
tion; 

selectively transmitting information between the first 
node and the second node via a selected one network 
connection; 

monitoring the at least two transport service providers for 

incoming information; and 
fetching and transferring incoming information to the 

appropriate application. 

8. A method as set forth in claim 7, further comprising the 

steps of: 

monitoring requests for connection received by the sec- 
ond node from the first node to connect one of the at 
least two transport service providers in tbe second node 
to a corresponding transport service provider in the first 
node; 

establishing network connection in response to a connec- 
tion request from the first node between the requested 
transport service provider of the second node and the 
corresponding transport service provider of the first 
node each time the second node receives a request for 
connection; 

after a first request for connection from the first node has 
been received, monitoring for a preselected period of 
time connection status of all of the at least two transport 
service providers to determine if each of the transport 
service providers has received a request for connection 
from the first node; 

after the preselected period of time has elapsed, reporting 
the connection status of the at least two transport 
service providers to the log. 

9. A method as set forth in claim 7, wherein network 
connection condition comprises network connection 
availability, cost, speed and wait time. 

10. A method as set forth in claim 7, wherein network 
connection selection is based upon a redundancy scheme 
and network connection condition. 

11. A method as set forth in claim 7, further comprising 
the steps of: 

in additional nodes, preparing at least two of the plurality 
of transport service providers for establishing a net- 
work connection through each of the at least two 
transport service providers and associating them with 
each other and the application in response to a request 
from the application to the interface for a single net- 
work connection; 

establishing network connection between each of the at 
least two transport service providers in the first node 
and corresponding transport service providers in at 
least one of the additional nodes. 

12. A method of managing a client-server communica- 
tions network having a plurality of nodes, each node capable 
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of running a plurality of applications and a plurality of 
transport service providers, each transport service provider 
linked to a network driver for establishing a network 
connection, an interface enabling any of the plurality of 
5 applications to communicate with each of the plurality of 
transport service providers and a manager module having a 
server manager and a client manager, coupling the interface 
and at least two of the plurality of transport service 
providers, the method comprising the steps of: 
10 in each of a first and a second node manager module, 
preparing at least two of the plurality of transport 
service providers for establishing a network connection 
through each of the at least two transport service - 
providers and associating them with each other and an 
application in response to a request from the applica- 
tion to the interface for a single network connection; 

in the server manager, 

monitoring connection requests between the first node 
and the second node to connect one of the at least 
two transport service providers in the first node to a 
corresponding transport service provider in the sec- 
ond node; 

establishing network connection through a requested 
transport service provider in response to a connec- 
tion request each time tbe connection request is 
received; 

after a first connection request has been received, 
monitoring for a preselected period of time connec- 
tion status of all of the at least two transport service 
providers to determine if each of the transport ser- 
vice providers has received a request for connection; 
after the preselected period of time has elapsed, report- 
ing the determined connection status of the at least 
two transport service providers to a log; 

in the client manager, 

providing connection requests between the first node 
and the second node to connect the at least two 
transport service providers in the first node to cor- 
responding transport service providers in the second 
node; 

monitoring for a preselected period of time receipt of a 
connection signal indicating an established network 
connection between each of the at least two transport 
service providers; 
after the preselected period of time has elapsed, report- 
ing the indicated connection status of the at least two 
transport service providers to the log; 
in the first and second node manager module, 
50 monitoring and ckitermining network connection con- 
dition; 

selectively directing information to a selected one 
network connection for transmission between the 
first node and the second node; 
55 monitoring established network connections for incom- 
ing information; and 
fetching and transmitting incoming information to the 
appropriate application. 
13. A method as set forth in claim 12, further comprising 
^ the steps of: 

in several additional nodes, preparing at least two of the 
plurality of transport service providers for establishing 
a network connection through each of the at least two 
transport service providers and associating them with 
65 each other and the application in response to a request 
from the application to the interface for a single net- 
work connection; 
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in the server manager of each of the first, second and 
several additional nodes, 

monitoring connection requests from all other nodes to 
connect one of the at least two transport service pro- 
viders in a requested node to a corresponding transport 
service provider in a requesting node; 

establishing network connection through a requested 
transport service provider in response to a connection 
request from the requesting node each time the 
requested node receives the connection request; 

after a first connection request from the requesting node 
has been received, monitoring for a preselected period 
of time connection status of all of the at least two 
transport service providers to determine if each of the 
transport service providers has received a request for 
connection from the requesting node; 

after the preselected period of time has elapsed, reporting 
. the determined connection status of the at least two 
transport service providers to an requested node log; 

in the client manager of one of the first, second and 
several additional nodes, 

providing connection requests to at least one other node to 
connect the at least two transport service providers in 
the any one node to corresponding transport service 
providers in the at least one other node; 

monitoring for a preselected period of time receipt of a 
connection signal from the at least one other node 
indicating an established network connection between 
each of the at least two transport service providers in 
the any one node and the corresponding transport 
service providers in the at least one other node; 

after the preselected period of time has elapsed, reporting 
the connection status of at least two transport service 
providers to the any one node log. 

14. A method as set forth in claim 12, wherein network 
connection condition comprises network connection 
availability, cost, speed and wait time. 

15. A method as set forth in claim 12, wherein network 
connection selection is based upon a redundancy scheme 
and network connection condition. 

16. A general purpose digital computer-based communi- 
cations network system having a plurality of nodes, each 
node comprising an output device, an input device, a CPU, 
memory, and a plurality of network cards, the CPU operating 
under control of an operating system program which con- 
trols the output device, the input device, the memory and the 
plurality of network cards, the memory comprising: 

an application program section for storing a plurality of 
applications; 

a network communications software section having a set 
of instructions for controlling the general purpose digi- 
tal computer to perform network connections between 
the plurality of nodes, the network communications 
software section comprising: 

a plurality of communications protocol stacks for estab- 
lishing a network connection to another node, each 
stack linked to one of the plurality of network cards; 

an interface section enabling any of the plurality of 
applications to communicate with any one of the 
plurality of communication protocol stacks; and 

a network manager section linked to at least two of the 
plurality of communications protocol stacks and the 
interface section, the network manager section com- 
prising: 

a stack connector section to prepare the at least two 
communications protocol stacks for establishing a 
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network connection through each of the at least 
two communications protocol stacks and associ- 
ating them with each other and a application in 
response to a request from the application to the 
interface section for a single network connection; 

a connection manager section to establish network 
connection from each of the at least two commu- 
nications protocol stacks of a first node to a 
corresponding communications protocol stack of a 
second node; 

a health manager section to monitor and determine 
network connection condition; and 

a transmission manager section to selectively trans- 
mit information via a selected one network con- 
nection. 

17. A general purpose digital computer-based communi- 
cations network system having a plurality of nodes, each 
node comprising an output device, an input device, a CPU, 
memory, and a plurality of network cards, the CPU operating 
under control of an operating system program which con- 
trols the output device, the input device, the memory and the 
plurality of network cards, the memory comprising: 

an application program section for storing a plurality of 
applications; 

a network cornmunications software section having a set 
of instructions for controlling the general purpose digi- 
tal computer to perform network connections between 
the plurality of nodes, the network communications 
software section comprising: 

a plurality of communications protocol stacks for estab- 
lishing a network connection to another node, each 
stack linked to one of the plurality of network cards; 

an interface section enabling any of the plurality of 
applications to communicate with any one of the 
plurality of communication protocol stacks; and 

a network manager section linked to at least two of the 
plurality of communications protocol stacks and the 
interface section, the network manager section com- 
prising: 

a stack connector section to prepare the at least two 
communications protocol stacks for establishing a 
network connection through each of the at least 
two communications protocol stacks and associ- 
ating them with each other and an application in 
response to a request from the application to the 
interface section for a single network connection; 

a server connection manager section to monitor 
requests for connection, received by a server node 
from a client node, to connect one of the at least 
two communications protocol stacks in the server 
node to a corresponding communications protocol 
stack in the client node; 

a client connection manager section to request con- 
nections from the client node to the server node to 
connect all of the at least two communications 
protocol stacks in the client node to corresponding 
communications stacks in the server node; 

a network connector section to establish network 
connection in response to a connection request 
from the client node between the requested com- 
munications protocol stack of the server node and 
the corresponding communications protocol stack 
of the client node, each time the server node 
receives a request for connection; 

a status manager section to monitor for a preselected 
period of lime connection status of all of the at 
least two communications protocol stacks, after a 
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first request for connection from the client node 
has been received to determine if each of the at 
least two communications protocol stacks has 
received a request for connection from the client 
node; 5 
reporter section to report the connection status of 
the at least two communications protocol stacks to 
a log after the preselected period of time has 
elapsed; 

health manager section to monitor and determine 10 
network connection condition; 
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a transmission manager section to selectively trans- 
mit application program information between the 
server node and the client node via a selected one 
of the network connections; 

a receive manager section to monitor the at least two 
communications protocol stacks for incoming 
application program information; and 

a transfer manager section to fetch and transfer 
detected incoming application program informa- 
tion to the appropriate application program. 



